共通データ構造を介した異なる型の構造へのアクセス

专利摘要:
共通データ型構造が、異なる型若しくは型構造に応じてデータを実装するアプリケーション間のアクセス要求を相互に関連付けるのに使用され得る。一実施形態において、共通データ構造は、（すなわち、未定義の）オペレーション、シーケンス、レコード、及びアトムに対するスキームを含む。そして、システムは、いかなる型の構造をも共通データ構造のスキームにマップすることができる。動作中、アプリケーションによるデータの要求は、アプリケーションによって使用される１つ以上のプロキシを識別して、データを前記共通データ構造にマップすることを含み得る。プロキシは、データのシェイプに基づいてデータを共通データ構造にマップする（それが識別されることができる程度に）。そして、プロキシは、識別されたマッピング情報を含む１つ以上のデータ構造を返信し得る。そして、アプリケーションは受信されたデータ構造に対して直接オペレーションを実行し得る。
公开号:JP2011515734A
申请号:JP2010548761
申请日:2009-01-23
公开日:2011-05-19
发明作者:エル．アンダーソン クリストファー；エー．ジパースキー クレメンス；ブラッドリー ケツァルコアトル；エス．ピンクストン ジェフリー；アール．ウィリアムズ ジョシュア；エフ．ボックス ドナルド；ジェイ．ガドジン マーティン
申请人:マイクロソフト コーポレーション；
IPC主号:G06F9-54

专利说明:

[0001] 本発明は、共通データ構造を介した異なる型の構造へのアクセスに関する。]
背景技術

[0002] コンピュータ化されたシステムの普及につれ、様々なアプリケーションプログラム及びドキュメントがコンピュータ化されたシステムで使用されてきた。特に、現在、複雑なオペレーティングシステム、データベース等として、機能するかどうか、又は、狭小な目的のために構成されたより簡単なアプリケーションプログラムとして機能するかどうか、いろいろな目的のために構成された広範囲のアプリケーションプログラムが存在する。多くの場合において、ソフトウェア開発者は、適切な種々のプログラミング言語を使用して特定のオペレーティングシステム／フレームワークを念頭において、新たなアプリケーションプログラムを作成するだろう。ソフトウェアが完成すると、開発者はアプリケーションをマシン実行可能コードにコンパイルするだろうし、そのマシン実行可能コードは適切なオペレーティングシステムを有するコンピュータシステムにインストールされ得る。多くの場合において、新たなアプリケーションプログラムを実行すると、システム／フレームワーク内のいくつかの他の要素又はアプリケーションを同時に利用する必要があるであろう。]
[0003] したがって、オペレーティングシステム若しくは汎用フレームワークの開発者並びにフレームワーク内で動作する個々のアプリケーションプログラムの開発者が考慮しなければならない多くの問題があることが十分理解されるだろう。これら関心の多くが一層競合し得る。例えば、多くのオペレーティングシステム／フレームワークの開発者が、セキュリティと安定性に関して興味を持っているものの、多くのアプリケーションプログラム開発者が、高速でかつカスタマイズ可能なオペレーションに関して興味を有し得る。ある場合には、セキュリティ及び安定性に関する要求により、いくつかのアプリケーションプログラムが動作する手法の速度とカスタマイズ性が制限されてしまう。]
[0004] この対立が明らかである１つの領域が、特定の種類の「型フレームワーク」にある。型フレームワークにおいて、関数、引数、及びデータ値さえも、特定の「型」と相関し得る。別のアプリケーション又は要素が対応するデータにアクセスし又はかかるデータを処理することができる前に、その特定の「型」は、種々のデータ（すなわち、関数、引数、又は値）がどのように現れる必要があるのかを一般的に定義する。強い型のフレームワークを採用するシステムにおいて、１つの型を使用するアプリケーション又は要素が他の型に対応する機能及びデータを実行し又はアクセスすることが禁止されるように、フレームワークは構成され得る。多くの異なる種類の型フレームワークがあるものの、いくつかの例示的フレームワークは、ノミナル（又は主格）構造型のフレームワークを含む。]
発明が解決しようとする課題

[0005] 一般に、１つのノミナル型のデータが、厳密に同一の型名を使用する（同一のノミナル型である）他のデータにアクセスのみし得る（又はアクセスのみされ得る）よう、ノミナル（又は主格）型のフレームワークが構成される。したがって、「顧客記録」と称する型名を使用する１つのアプリケーションは、型構造（例えば、記録フィールド等の数と名前）は同一であり得るものの、「メンバ記録」と称する型名の下で別のアプリケーションによって管理された類似のデータにアクセスすることが禁止され得る。例えば、顧客記録のノミナル型とメンバレコードのノミナル型の双方が等しい数と種類のフィールド（例えば、第１の名称＝「文字列、」及び第２の名称＝「文字列、」等を含むセット）を含む場合において、構造上の同一性が生じ得る。対照的に、構造型フレームワークは、名称よりもむしろ構造間の一致に依存している。構造型は不正確な型名称に制限されないものの、型のうちの１つが、別の型よりも多くの種類の構造又は異なる種類の構造（例えば、メンバレコードは、第１の名称＝「文字列、」、第２の名称＝「文字列、」及び電話番号＝値を含む）を含むときに、構造の不一致が生じ得る。]
[0006] 多くの場合、ノミナル型及び構造型を含む種々の異なる型間の不一致に対して、種々の回避方法があるので、アプリケーションが相互利用することができる。ノミナル型フレームワークにおいて、例えば、開発者は対象となる各アプリケーションのために新たなコードを作成し得る。その新たなコードは、１つのノミナル型の型構造を別のノミナル型の同一の型の構造にマップし又は変換する。また、合致していない型構造間において類似の回避方法も可能であるものの、構造型のそのような変換は、より複雑である傾向がある。例えば、Ｌｉｓｐプログラミング言語は、基本構造はデータのペアである１つの共通の従来の構造型フレームワークを実装する。したがって、別のアプリケーションプログラムのデータを使用するために、Ｌｉｓｐベースのアプリケーションは、他方のアプリケーションにおけるデータ構造をデータペア構造に変換する必要が通常あり、これは困難であり得る。]
[0007] 同様に、Ｌｉｓｐデータペア構造から別のアプリケーションの別の型の構造に変換することは、難しい場合がある。これが正しいのは、データがＬｉｓｐにおいてどのように配置されるかという点における差異だけでなく、Ｌｉｓｐデータペアの値は、データペアの計算上効果で完全なトラバースをすることなく、確かめることが多くの場合困難であるからである。この原因は、部分的には、データペアが「シーケンス」であることを除いて、Ｌｉｓｐデータペアが基本的なクエリを介して非常に多くの情報を提供しない傾向があるからである。しかしながら、Ｌｉｓｐプログラミングフレームワークは、異なる型の構造に関する問題を提示し得る唯一の言語でない。各々が自身の異なる構造型フレームワークを使用する他の共通言語はＸＭＬ、ＳＱＬ、．ＮＥＴ、及びＪａｖａを含み、相互利用は多くの場合いくつかの型構造の変換を意味する。]
[0008] 従って、アプリケーションプログラム間の相互利用を確実にする１つの手法が、あらかじめ適切であるとしてノミナル構造及び／又は型構造の詳細に一致する類似のプラットフォーム上で作業するアプリケーション開発者のためにある。もちろん、そのような厳密で正確な一致は必ずしも可能ではなく、後に同じシステムで使用されるだろう要素を作成し得る他の開発者に対して柔軟性をほとんど提供しない。したがって、開発者は、（先に説明したように）１つ以上のインタフェースを作成するはめに多くの場合なってしまう。その１つ以上のインタフェースは、より新しいアプリケーションの型のデータを別のアプリケーションの型のデータに変換し又はマップする。例えば、１つの構造型フレームワークで作成されたアプリケーションを作成する開発者は、Ｌｉｓｐプログラミング言語で作成された他のアプリケーションに対する１つのアダプタを作成する必要があり得るし、そして／又は、場合によっては、ＸＭＬ、ＳＱＬ、．ＮＥＴ、及びＪａｖａプログラミング言語の各々で作成されたアプリケーションに対する個別のアダプタを作成する必要があり得る。]
[0009] これは新たなアプリケーションプログラムの開発者が他のプログラムで使用される型に関して知る（学習する）必要があるだろうということを意味していると、十分理解されるだろう。考慮すべき少数のアプリケーションにおいて、この問題はよりいっそうの不便が生ずる。しかしながら、より一般的には、特に、システム上の類似の又は同一の種類のデータ（例えば、会員資格記録、機能等）を使用するアプリケーションプログラムの数が増大するにつれて、この種のシナリオにより多くの開発者にとって問題が指数関数的に増大してしまう。さらにこの問題は悪化せしめられ得る。種々のアプリケーションプログラムの各々が変更し得るし種々なアップグレードによって変更され得るからであり、これにより、型名及び又は構造がさらに一層変更されうる結果となり得る。]
[0010] 従って、型ベースのフレームワークにおいて解決され得る多くの困難がある。]
課題を解決するための手段

[0011] 本発明の実施形態は、１つのアプリケーション又は要素によるアクセスを、共通／ユニバーサルデータ構造を介して、事実上すべての他のアプリケーションのすべてのデータに対して提供するように構成されているシステム、方法、及びコンピュータプログラムプロダクトにまで及ぶ。一実施形態において、例えば、アプリケーションによるデータの要求は、１つ以上のプロキシの始動を含み得る。その１つ以上のプロキシは、別のアプリケーションのデータを共通データ構造の１つ以上のスキーマにマップすることができる。そして、要求するアプリケーションは、プロキシによって作成されて返信された（マッピング情報の）データ構造を介して、要求されたデータと情報のやり取りを行うことができる。その結果、アプリケーションがあらかじめ共通データ構造を必然的に認識しているか否かに関係なく、そして、アプリケーションが他のアプリケーションで使用された特定の型の構造に従って自身のデータを構成しているか否かに関係なく、システムの各アプリケーションは、相互利用することができる。]
[0012] 従って、全体的なシステムの観点からの方法は、１つ以上の異なるアプリケーションによって保持されたデータに対する１つ以上のアクセス要求をアプリケーションから受信することを含み得る。この場合、当該要求されたデータは１つ以上の異なる型の構造に対応する。また、方法は、前記１つ以上の異なるアプリケーションに対応する１つ以上のプロキシを識別することを含み得る。さらに、方法は、当該識別された１つ以上のプロキシを使用して、当該要求されたデータを共通データ構造にマップすることを含み得る。当該識別された１つ以上のプロキシは、当該要求されたデータを前記共通データ構造にマップするマップされたデータ構造を作成する。その上、方法は、当該マップされたデータ構造を前記要求するアプリケーションに提供することを含み得る。]
[0013] さらに、アプリケーションの観点から方法は、１つ以上の異なる型の構造に対応するデータに対して１つ以上のアクセス要求を送信することを含む。また、方法は、当該要求されたデータと共通データ構造の１つ以上の構造型との間のマッピング情報を含む１つ以上のマップされたデータ構造を受信することを含む。さらに、方法は、１つ以上のマップされたデータ構造に対して１つ以上の動作を要求することを含み得る。この場合、当該要求された１つ以上の動作は、前記１つ以上の異なる型の構造の前記データに変換される。その上、方法は、前記１つ以上の要求された動作が前記１つ以上の異なる型の構造に対応する前記要求されたデータに対して完了した旨の１つ以上の確認を受信することを含み得る。]
[0014] 本概要は、発明の詳細な説明においてさらに後述する単純化した形態での概念の選択を導くために与えられている。この発明の概要は、特許請求の範囲に記載された発明の重要な特色若しくは本質的な特徴を特定することを目的としておらず、又は、特許請求の範囲に記載された発明の範囲を決定する際の補助手段として利用されることを目的としていない。]
[0015] 本発明の更なる特徴及び利点が以下の詳細な説明に部分的に記述されており、詳細な説明から部分的に明らかとなり、又はこの発明の実施によって理解されるであろう。本発明の特徴及び利点は、添付された請求の範囲において特に指摘された手段及び組合せによって認識され且つ得られるであろう。本発明のこれら特徴及び他の特徴は、以下の説明及び添付した請求の範囲から、より完全に明らかになるだろうし、又は、以下に詳細に説明するように、本発明の実施によって理解され得る。]
[0016] 本発明の上述の利点及び他の利点及び特徴が理解され得るように説明するために、簡単に上記説明された本発明のさらなる特定の説明が、添付図面に図示された特定の実施形態を参照することによって提供されるだろう。これら図面は本発明の典型的実施形態のみを示すものであり、本発明の範囲を限定するものとして考慮されるべきものでないことを理解すれば、本発明は、添付図面を使用してさらなる特異性及び詳細と共に、記述され且つ説明されるだろう。]
図面の簡単な説明

[0017] １つ以上の異なる型の構造を実装する１つ以上のアプリケーションプログラムが共通のデータ構造を介して相互利用する本発明の実施形態に係る概要概略図である。
プロキシがデータを共通のデータ構造にマップするように始動せしめられる図１Ａの概略図である。
アプリケーションが別のアプリケーションのデータをマップされたデータ構造を介して相互利用する図１Ａー図１Ｂの概略図である。
共通データ構造を使用して、データにアクセスするか若しくは異なる構造型のデータへのアクセスを提供するアプリケーションプログラム及び全体的なシステムの観点に基づく方法のフロー図である。] 図１Ａ 図１Ｂ
実施例

[0018] 本発明の実施形態は、１つのアプリケーション又は要素によるアクセスを、共通／ユニバーサルデータ構造を介して、事実上すべての他のアプリケーションのすべてのデータに対して提供するように構成されたシステム、方法、及びコンピュータプログラムプロダクトにまで及ぶ。一実施形態において、例えば、アプリケーションによるデータの要求は、１つ以上のプロキシの始動を含み得る。その１つ以上のプロキシは、別のアプリケーションのデータを共通データ構造の１つ以上のスキーマにマップすることができる。そして、要求するアプリケーションは、プロキシによって作成されて返信された（マッピング情報の）データ構造を介して、要求されたデータと情報のやり取りを行うことができる。その結果、アプリケーションがあらかじめ共通データ構造を必然的に認識しているか否かに関係なく、そして、アプリケーションが他のアプリケーションで使用された特定の型の構造に従って自身のデータを構成したか否かに関係なく、システムの各アプリケーションは、相互利用することができる。]
[0019] 従って、及び、本明細書において完全に理解されるように、本発明の少なくとも１つの実施形態は、共通データ構造（若しくは「ユニバーサルデータモデル」）を提供することに関連する。共通データ構造／ユニバーサルデータモデルは、言い換えると、「アトム」、「シーケンス」、「レコード」、又は「オペレーション」に関して、システムのすべてのアプリケーションのデータをも定義し若しくは分類する。共通データ構造又は別のアプリケーションによって使用される型構造に従う所定のアプリケーションのデータが厳密に分類若しくは構成されていなくとも、この分類システムは、開発者がアプリケーションを開発しているポイントだけでなく、ランタイムにおいても、使用され得る。]
[0020] したがって、このシステムは広く拡張可能であり得るし、多くの異なるフレームワーク内で存在し又は使用され得ることが十分理解されるだろう。例えば、本発明の実施形態は、共通言語ランタイム（「ＣＬＲ」：common language runtime）環境における使用のために、及び／又は、すべての特定の言語フレームワークに関しても、容易に構成され又は拡張され得る。例えば、本発明の少なくとも１つの実施形態は、ＸＭＬに基づくアプリケーションにも特に利用可能である。実際、基本的なデータのシェイプが何らかのポイントで決定され得る限り、事実上全ての言語若しくはランタイム環境が使用され得る。]
[0021] 図１Ａは、本発明の実施形態に係る概要概略図を示しており、その実施形態は、システム１００の１つ以上の異なるアプリケーション又は要素が共通データ構造を介して互いに情報のやりとりを行う。例えば、図１Ａは、１つ以上の処理モジュール１０５を含むシステム１００について図示しており、その１つ以上の処理モジュール１０５は共通データ構造（「ユニバーサルデータモデル」）１１０に対して１つ以上のリファレンスをさらに含む。少なくとも１つの実施形態において、システム１００は、ノミナル型の環境のサブスペース内で構成された一般化された構造型のシステムを含む。例えば、システム１００は、ＣＬＲベースのノミナル型環境内で実装される共通構造型のシステムを含み得る。] 図１Ａ
[0022] さらに、図１Ａは、共通データ構造１１０が１つ以上のスキーマを含み、その１つ以上のスキーマが、特定のデータ「シェイプ（shape）」に関連する特定の構造型及びスキーマを定義することを示している。また、本明細書において完全に理解されるように、データ「シェイプ」とは、共通データ構造１１０に関してデータ要素を広く分類するのに使用され得るデータ要素の基本的であり識別可能な特徴を意味している。例えば、図１Ａは、共通データ構造１１０が、データシェイプ１３５を有してオペレーションに対する構造型スキーマと、データシェイプ１４０を有してシーケンスに対する構造型スキーマと、データシェイプ１４５を有してレコードに対する構造型スキーマと、を含むことを示している。また、図１Ａは、共通データ構造１１０が「アトム」に対する構造型スキーマをさらに分類することを示しており、その「アトム」に対する構造型スキーマは本質的には未定義のデータシェイプ（すなわち、「---」）を有するものである。] 図１Ａ
[0023] 一般に、「オペレーション」とは、個別又はすべてのセットの他の機能の一部にかかわらず、実行され又は処理されるときに結果を返信する関数又は引数であるとデータを識別するデータシェイプを有する１つ以上のデータ要素のあらゆるセットをも意味している。少なくとも１つの実施形態において、例えば、オペレーションは、本質的にはコアとして、データの呼び出しできるピースとして解釈され得る。ＣＬＲに関して、ＣＬＲインスタンスを共通データ構造１１０にマップする際に、「方法」及び「デリゲイト」はオペレーションとして解釈され得る。そのため、ＣＬＲ環境におけるオペレーションは、不特定数の「StructuredValue」パラメータを取って、「StructuredValue」を返すデリゲイトとして理解され得る。少なくとも１つの実施形態において、StructuredValueは、構造化された値を動作せしめるコードのインスタンスを分類するヘルパーとして提供される特定のノミナル型である。さらに、型StructuredValueは、構造化されたスペースに導入されている値を作動させると明確に予想するマーカ型としてＡＰＩ（アプリケーションプログラムインターフェイス）上で使用され得る。]
[0024] さらに、「シーケンス」とは、本明細書において、値の１つ以上の（順不同の）集合のあらゆるセットのデータシェイプを有するデータをいう。ＣＬＲ環境に関し、例えば、シーケンスは「StructuredValues」の順不同の集合として理解され得る。一般に、シーケンスは、個別にラベル付けされていない値を含み、又は、ラベル若しくは名前が各値の単位で固有でないか若しくはシステム１００の観点からすれば集合の値を区別するには不十分である値を含む。]
[0025] 対照的に、レコードの値が１つ以上の固有のフィールド名等の１つ以上の固有のラベルに関連づけられる更なるシェイプの特徴を有することを除いて、「レコード」はシーケンスのような値の集合のシェイプを有するデータを含む。ＣＬＲ環境の少なくとも１つの実施形態において、例えば、レコードは、（自身が各々いくつかの「StructuredValue」である値を有する）１セットの名前を付されたメンバとして解釈され得るし、レコードが読み取り専用であるかを示すフラッグとして解釈され得る。したがって、かかる環境において、レコード及びシーケンスは、データシェイプを表現する主要な機構と解釈され得ることが十分理解され得る。]
[0026] もちろん、上記の説明にもかかわらず、１つの特定のオペレーティングシステム若しくはアプリケーションプログラムにおいていくつかの特定的用法を有し得るすべての特定の要素、機能、又は動作環境に対する本明細書における言及は、描写的な利便性を目的としていることが十分理解されるだろう。特に、本出願の明細書及び請求の範囲から、本発明の実施形態が、広範な範囲の動作環境及びオペレーティングシステム、及び／又は、フレームワーク／環境において実施され得ることが十分理解できるだろう。したがって、特定のオペレーティングシステム又はアプリケーションプログラムに限定するものと解釈するべきでない。]
[0027] いずれにせよ、図１Ａは、システム１００が１つ以上のアプリケーション又は要素１２０、１２５、及び１３５を含むことをも示す。その１つ以上のアプリケーション又は要素１２０、１２５、及び１３５は、本明細書により完全に説明されているように、共通データ構造１１０の利益を享受する。例えば、図１Ａは、アプリケーション１２０、１２５、及び１３０の各々がデータセット１２３、１２７、及び１３３をそれぞれ含む。それらデータセット１２３、１２７、及び１３３は共通データ構造１１０のスキーマの１つに対応してもよいし又は対応しなくてもよい。特に、図１Ａは、アプリケーション１２０がデータ要素Ａ、Ｂ、及びＣを含むデータセット１２３を含むことを示している。この場合、データ要素Ａ、Ｂ、及びＣは、対応するデータシェイプ１３５、１４０、及び１４５に少なくとも部分的にそれぞれ基づいて、オペレーション、シーケンス、又はレコードの構造型にそれぞれ対応している。] 図１Ａ
[0028] 対照的に、図１Ａは、型構造とデータシェイプが共通データ構造１１０に関して明確に定義されないものの、アプリケーション１２５及び１３０がデータセットをも含むことをも示している。例えば、図１Ａは、アプリケーション１３５がデータ要素Ｄ、Ｅ、及びＦに関するデータセット１２７を含むことを示している。これらのうち、データ要素Ｄだけが、データシェイプ１３５に基づいて「オペレーション」の構造型に対応することが知られている。特に、図１Ａは、データ要素Ｅがデータシェイプ１４５を有し、Ｅが特定の構造型にまだ関連づけられていないことを示している。同様に、データ要素Ｆは、構造型に関連づけられておらず、既知のデータシェイプを含まない。] 図１Ａ
[0029] さらに、図１Ａは、アプリケーション１３０がデータ要素Ｇ、Ｈ、Ｉ、及びＪを含むデータセット１３３を含むことを示している。これらのうち、データ要素Ｇ、Ｈ、及びＩはそれぞれ識別可能なデータシェイプ１４０、１３５、及び１４５を有する。しかしながら、図示されているように、データ要素Ｉのみがレコードの構造型に対応するものと識別されている。その上、図１Ａは、データ要素Ｊが、識別された構造型も、容易に識別可能なデータシェイプをも有しないことを示している。] 図１Ａ
[0030] したがって、（アプリケーション１２０に比較された）アプリケーション１２５及び／又は１３５の種々のデータ要素における構造／型の観点から識別される差異は、いくつかの因子に依存し得ることが十分理解されるだろう。アプリケーション１２０に関して、例えば、開発者は、共通データ構造１１０及び要求されたスキーマの知識を考慮して、アプリケーション１２０を作成したかもしれないし、適切な構造型を有するデータ要素Ａ、Ｂ、及びＣを宣言したかもしれない。したがって、アプリケーション１２０のインストールの際に、処理モジュール１０５は、データ要素Ａ、Ｂ、及びＣの各々が共通データ構造１１０の図示された型及びデータシェイプに対応することを直ちに識別するように構成され得る。]
[0031] 対照的に、アプリケーション１２５及び／又は１３０の開発者は、特定の明確に定義されたデータシェイプを使用して、初めにアプリケーション１２５及び／又は１３０を作成したかもしれないし、他の異なる型のフレームワークに基づいて特定の構造型を宣言したかもしれない。したがって、インストールの際に、又は、データがシステム１００によって識別された他のいくつかのポイントにおいて、アプリケーション１２５及び１３０が、共通データ構造１１０に対応する型構造の識別を具体的に提供してはいないかもしれない（又は、システム１００は型構造を識別しなかった）。あるいは、アプリケーション１２５及び１３０は、共通データ構造１１０を考慮して開発されたかもしれないものの、何らかの理由のために、データ要素Ｄ−Ｊは処理モジュール１０５によって未だ識別されておらず、又は、特定の構造型に関連付けられていない。]
[0032] 一般に、構造の型が特定のデータ要素に関連づけられ得る多くの方法がある。例えば、その関連付けられた型構造とデータ要素のシェイプとをインストール等の際に処理モジュール１０５に対して発行するように、アプリケーションは構成され得る。同様に、アプリケーションは、所定のアプリケーションによって管理されたデータ（すなわち、データセット１２３）が共通データ構造１１０に一致することを識別する１つ以上のメッセージを用いて、（例えば、インストール中又はランタイム中に）処理モジュール１０５に単に応答し得る。しかしながら、本発明の少なくとも１つの利点は、１つ以上のプロキシ（例えば、１６５、１７０、１７５）を使用して、この情報の多く又はすべてがランタイムにて判断され得るということである。例えば、図１Ａは、システム１００がプロキシのレジストリ１１５を含み。そのプロキシのレジストリ１１５は、この場合、アプリケーション１２０に基づいたプロキシ１６５を少なくとも含むことを示している。また、図１Ａは、レジストリ１１５がアプリケーション１２５に基づくプロキシ１７０、及びアプリケーション１３０に基づくプロキシ１７５を含むことを示している。] 図１Ａ
[0033] 単に説明として、「プロキシ」とは、システム１００において呼出され且つ特定のアプリケーションと連動させるのに使用される１つ以上のコンピュータ実行可能命令のセットを意味する。一実施形態において、これらプロキシは、既にコンパイルされて実行可能な命令として存在し得る。その既にコンパイルされて実行可能な命令は、事実上いつでも呼出しされ得る。しかしながら、さらなる実施形態又は代替実施形態において、これらプロキシは、システム１００によって提供され且つ呼出される場合に最初にコンパイルされて実行される中間言語コードの形態を含み得る。いずれの場合においても、プロキシは、所定のアプリケーションプログラムに適切な特定のプログラム言語で作成されたようなアプリケーションに特有なものであり得ることが十分理解されるだろう。例えば、所定のプロキシは、特に、ＸＭＬ、ＳＱＬ、Ｌｉｓｐ等で作成されたプログラムに対して構成され得る。ＣＬＲに基づく少なくとも１つの実施形態において、例えば、「ClrStructureServices」として知られているプロキシは、「StructuredValues」に対してＣＬＲインスタンスを表すように構成され得る。]
[0034] これらプロキシは、アプリケーション開発者によって作成され得るし、又は、システム１００によって単に提供され得る。例えば、（アプリケーション１２０、１２５、１３０等の）アプリケーション開発者は、所定のアプリケーションに特有の１つ以上のプロキシを準備し得るし、アプリケーションのインストールの際にそのプロキシを登録し得る。ある場合には、いくつかの開発者にとって、この事は望ましいかもしれない。アプリケーション開発者は、プロキシがデータ要素を未定義の「アトム」として過度に分類することを避けることを確実になすより良い立場にあり得るからである。しかしながら、他の場合において、アプリケーション開発者は、共通データ構造１１０の構造型内で定義されたシェイプに少なくとも部分的に一致するそれらデータを準備し得るし、そういうものとして、開発者はデフォルトのプロキシを使用するという利便性を選択してもよい。]
[0035] 一般に、実行されると、所定のプロキシがアプリケーション（１２０、１２５、１３０等）によって保持された１つ以上のデータ構造又は要素にトラバースするように、各プロキシが構成されている。トラバースの際に、プロキシは、様々なデータ要素の「シェイプ」を識別するように最小限で構成される。上記から分かるように、これは、アプリケーションによって保持されたデータ要素が、ある最小のプロパティ（例えば、結果を返す）に従う機能又は引数であるか否かをプロキシコードが識別するように通常構成されるだろうということを意味している。本明細書に記載されるように、共通データ構造１１０のスキーマに対して、あるデータ要素が値の集合を形成するか否か、及び／又は、それら値がシーケンス若しくはレコードとしてデータ要素を分類し得る付加的ラベリングを含むか否かを識別するように、同一のプロキシは構成されるだろう。]
[0036] 図１Ｂは、システム１００が、１つ以上のプロキシの幇助により、１つ以上のアプリケーション１２５及び１３０内のデータに対するアクセスをアプリケーション１２０に提供する概要概略図を示している。例えば、図１Ｂは、アプリケーションプログラム１２０が、１つ以上のデータアクセス要求１８０を送信して、アプリケーション１２５によって保持されたデータのアクセスを要求することを示している。この要求は、処理モジュール１０５を介する等して、システム１００によって処理される。要求は、（アプリケーション１２０と比べて）異種の／互換性がない型の構造に対応するデータを含むので、図１Ｂは、処理モジュール１０５がプロキシレジストリ１１５に問い合わせて、いかなるプロキシがアプリケーション１２５の型構造を共通データ構造１１０にマップするのに使用されるべきであるかを識別することを示している。従って、図１Ｂは、処理モジュール１０５は、プロキシ１７０がアプリケーション１２５と相関することを識別し、要求１８５を介してプロキシ１７０を（すなわち、実行時間中に）始動することを示している。] 図１Ｂ
[0037] さらに、図１Ｂは、プロキシ１７０がアプリケーション１２５に関して初期化されることを示している。少なくとも１つの実施形態において、プロキシ１７０は異なるデータ要素Ｄ、Ｅ、Ｆ等の各々に行き来し始める。これは、利用可能な全ての構造型の同一性を識別し、且つ／又は各データ要素のデータシェイプを識別することを目的とする。少なくとも１つの実施形態において、例えば、プロキシ１７０は、データ要素Ｄが共通データ構造１１０に対する構造型フレームワーク内で理解されるようなオペレーションを含むことを識別する。さらに、プロキシ１７０は、データ要素Ｅがデータシェイプ１４５を有することを判断し得る。そのデータシェイプ１４５は、共通データ構造１０５のレコードに対する構造型に使用されるシェイプと一致する。その上、プロキシ１７０は、データシェイプのすべての構造型がデータ要素Ｆと同一であると識別し得ないので、データ要素Ｆをアトムとして割り当てる。] 図１Ｂ
[0038] データ要素に関してこのトラバース及びマッピングを終了する際に、プロキシ１７０は１つ以上のデータ構造を返信する。その１つ以上のデータ構造は、トラバースされた（又は要求された）データ要素を共通データ構造にマップする。例えば、図１Ｂは、プロキシ１７０が処理モジュール１０５を介してマップされたデータ構造１９５を送信することを示している。処理モジュール１０５はマップされたデータ構造１９５をアプリケーション１２０に送る。さらなる実施形態又は代替実施形態において、処理モジュール１０５は、マップされたデータ構造１９５が作成されていることを示すメッセージをアプリケーション１２０に単に返信し、さらに、アプリケーション１２０がマップされたデータ構造１９５にアクセスするのに使用することができる１つ以上のレファレンスを提供する。そして、アプリケーション１２０は、マップされたデータ構造１９５に関するマッピングを使用して、アプリケーション１２５におけるデータに対して１つ以上の動作を実行する。] 図１Ｂ
[0039] 例えば、図２は、アプリケーション１２０が、マップされたデータ構造１９５を介してアプリケーション１２５のデータを相互利用する少なくとも１つの例を示している。例えば、図２は、マップされたデータ構造１９５が、共通データ構造スキーマとアプリケーション１２５のデータ要素との間のマッピング若しくは相関情報を含むことを示している。特に、図２は、マップされたデータ構造１９５が、データ要素Ｄをオペレーションとして定義し若しくは関連付けるマッピング２１０を含むことを示している。さらに、図２は、マップされたデータ構造が、データ要素Ｅをレコードとして定義し若しくは関連付けるマッピング２２０、及び、データ要素Ｆをアトムとして定義し若しくは関連付けるマッピング２３０を含むことを示している。そして、アプリケーション１２０は、これら種々のマッピングを参照することによって、アプリケーション１２５のデータを操作し若しくは使用することができる。] 図２
[0040] 例えば、図２は、アプリケーション１２０が要求２００を処理モジュール１０５に送信することを示している。この場合、要求２００は、レコードＥを「Ｅ´」に変更して、レコードＥを作成する要求を含む。この要求を処理するために、図２は、処理モジュール１０５が、マップされたデータ構造１９５に対するリファレンスを介して要求２００を処理することを示している。一実施例において、これは、処理モジュール１０５が要求２００をマッピング情報と結合し、新たな要求（若しくは変更された形態の要求２００）をアプリケーション１２５に送信することを意味している。例えば、図２は、処理モジュール１０５が要求２４０をアプリケーション１２５に送ることを示している。アプリケーション１２５は、要求２４０に含まれるマッピング情報２２０を理解しているので、アプリケーション１２５は、アプリケーション１２０からのデータ要素Ｅを変更するという要求を理解し、処理し得る。] 図２
[0041] そういうものとして、アプリケーション１２５は要求を処理し、通信チャネルを介して確認を送り返す。例えば、図２は、アプリケーション１２５が、データ要素Ｅが要求された通りＥ’に変更されたことを確認する応答２５０を準備し且つ送信することを示している。一実施例において、これは、メッセージ２５０を処理モジュール１０５に送信することを含み、そして、処理モジュール１０５がメッセージをアプリケーション１２０に転送する。その結果、アプリケーション１２０は、アプリケーション１２５によって使用された型コンベンションに関する詳細な知識を有することなく、アプリケーション１２５によって管理された１つ以上のデータ要素を操作した。] 図２
[0042] 従って、図１Ａ、１Ｂ、及び２は、データにおける特定の構造型の割り当てに実質的に関係なく、アプリケーション間でデータを処理する多くの異なる概略図、要素、及び図を示している。むしろ、アプリケーションが互いを相互利用するために、考慮されなければならないすべてが、データの最も基本的なシェイプである。強くシェイプ付けされたシステムの重要な性能及びセキュリティ上の利点を保持するにもかかわらず、柔軟にシェイプ付けされたシステムには通常一般的であるような（すなわち、特定の型のコンベンションを懸念する必要なく）極めて高い柔軟性が、これにより開発者に提供され得ることが十分理解されるだろう。] 図１Ａ
[0043] 前述に加えて、また、本発明の実施形態は、特定の結果を達成する１つ以上の動作を含む方法に関して、説明され得る。例えば、図３は、共通データ構造を使用して異なる構造の型に対応するデータにアクセスするか若しくはデータへのアクセスを提供する。図１Ａから図２の要素及び図に関して図３に示された動作について説明する。] 図１Ａ 図２ 図３
[0044] 例えば、図３は、アプリケーション１２０の観点からの方法が、データアクセス要求を送信する動作３００を含み得ることを示している。動作３００は、１つ以上の異なる型の構造に対応するデータに対して１つ以上のアクセス要求を送信することを含む。例えば、図１Ｂに示されているように、アプリケーション１２０は、アクセス要求１８０を処理モジュール１０５に送信する。同様に、要求１８０は、別のアプリケーション（例えば、１２５）によって保持されたいくつかのデータのアクセス又は操作を含む。その別のアプリケーション（例えば、１２５）は、別の型の構造（若しくは明確に定義されていない型の構造）を使用している。] 図１Ｂ 図３
[0045] また、図３は、アプリケーション１２０の観点からの方法が、データを共通データ構造にマップするデータ構造を受信する動作３１０を含み得ることを示している。動作３１０は、当該要求されたデータと共通データ構造との間のマッピング情報を含む１つ以上のデータ構造を受信することを含む。例えば、図１Ｂに示されているように、アクセス要求１８０を受信する際に、処理モジュール１０５は、１つ以上の要求１８５を送信して、プロキシ１７０を始動する。そして、プロキシ１７０はアプリケーション１２５におけるデータ構造に行き来して、様々なデータシェイプが識別されることができる程度に、識別して、マップされたデータ構造１９５を返信する。そのマップされたデータ構造１９５は、要求されたデータを共通データ構造１１０に相互に関連付ける。] 図１Ｂ 図３
[0046] さらに、図３は、アプリケーション１２０の観点からの方法が、受信されたデータ構造を介して要求されたデータに対してオペレーションを実行する動作３２０を含み得ることを示している。動作３２０は、１つ以上のデータ構造に対して１つ以上の動作を要求することを含み、当該要求された１つ以上のオペレーションは、１つ以上の異なる型の構造に対応する。例えば図２に示されているように、アプリケーション１２０は、データ構造１９５におけるデータ要素ＥをＥ´に変更する要求を含む要求２００を処理モジュール１０５に送信する。そして、この要求はマップされたデータ構造１９５及びメッセージ２４０を介して転送され、アプリケーション１２５を介して続いて処理される。] 図２ 図３
[0047] その上、図３は、アプリケーション１２０の観点からの方法が、オペレーションが完了していることを確認する動作３３０を含み得ることを示している。動作３３０は、前記１つ以上の要求された動作が前記１つ以上の異なる型の構造に対応する前記要求されたデータに対して完了した旨の１つ以上の確認を受信することを含む。例えば、図２は、データ要素Ｅに対応するレコードがＥ´に変更されたことを確認するアプリケーション１２５が、１つ以上の確認応答２５０をアプリケーション１２０に送り返すことを示している。] 図２ 図３
[0048] 前述に加えて、図３は、全体的なシステム１００の観点からの方法が、異なる型の構造に対応するデータを要求するアクセス要求を受信する動作３４０を含み得ることを示している。動作３４０は、１つ以上の異なるアプリケーションによって保持されたデータに対する１つ以上のアクセス要求をアプリケーションから受信することを含み、当該要求されたデータは１つ以上の異なる型の構造に対応する。例えば、図１Ｂは、システム１００が、処理モジュール１０５を介して、アプリケーションプログラム１２０から要求１８０を受信して、アプリケーション１２５のデータにアクセスすることを示している。この場合は、少なくとも１つのデータ要素がアプリケーション１２５に対して定義されるものの、他のデータ要素のいくつかは特定の構造型を有しておらず且つデータシェイプ（例えば、データ要素Ｅ）のみ有する。] 図１Ｂ 図３
[0049] また、図３は、システム１００の観点からの方法が、異なる型の構造に対する対応するプロキシを識別する動作３５０を含み得ることを示している。動作３５０は、前記１つ以上の異なるアプリケーションに対応する１つ以上のプロキシを識別することを含む。例えば、図３は、処理モジュール１０５が、要求１８０を受信する際に、プロキシ１７０がアプリケーション１２５と相関することをレジストリ１１５において識別し、１つ以上の要求１８５を送信して、プロキシ１７０を始動することを示している。] 図３
[0050] さらに、図３は、システム１００の観点からの方法が、当該要求されたデータを共通データ構造にマップする動作３６０を含み得ることを示している。動作３６０は、当該識別された１つ以上のプロキシを使用して、当該要求されたデータを共通データ構造にマップすることを含み、当該識別された１つ以上のプロキシはマップされたデータ構造を作成する。例えば、プロキシ１７０はデータ要素に行き来し、例えば、どのデータシェイプが、共通データ構造１１０のどの構造型に対応するのかを識別する。そして、プロキシ１７０は、マッピング情報を含むデータ構造１９５を作成する。そのマッピング情報は、要求されたデータ要素を共通データ構造の構造型に関連付ける（又は指定する）。] 図３
[0051] その上、図３は、システム１００の観点からの方法が、マッピング情報を含むデータ構造を共通データ構造に送信する動作３７０を含むことを示している。動作３７０は、当該マップされたデータ構造を前記要求するアプリケーションに提供することを含む。例えば、図１Ｂに示されているように、処理モジュール１０５はマップされたデータ構造１９５をアプリケーション１２０に送信する。上述したように、アプリケーション１２０は、マップされたデータ構造１９５に適切にマップされたアプリケーション１２５におけるデータのいずれも操作することができる。] 図１Ｂ 図３
[0052] 従って、図１−３及び対応する本文は、種々のアプリケーションが異なる型のフレームワークで構築され得るものの、それらアプリケーションが互いのデータにアクセスし得ることを確実になす多くの要素及び機構を提供する。先に説明したように、本発明の少なくとも１つの利点は、開発者が特定の型のコンベンションよりむしろデータシェイプに対する考慮を主に依存することができるということである。型コンベンションを時々変更することよりも、データシェイプに関して集中することによって、旧来の若しくは新規な型のフレームワークで構築されたアプリケーションは、多数のオペレーションを享有することが可能となる。]
[0053] 本発明の実施形態は、以下でさらに詳細に説明するように、種々のコンピュータハードウェアを含む専用若しくは汎用のコンピュータを含み得る。また、本発明の範囲内の実施形態は、コンピュータ実行可能命令又はデータ構造を転送し若しくは有するコンピュータ読取可能媒体を含む。かかるコンピュータ読取可能媒体は、汎用若しくは専用コンピュータによってアクセスされ得る全ての利用可能な媒体であり得る。]
[0054] 限定ではなく、実施例として、かかるコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、他の光ディスク記憶装置、磁気ディスク記憶装置、他の磁気記憶装置、又はいかなる他の媒体を含み得る。その他の媒体は、コンピュータ実行可能命令又はデータ構造の形態で所望のプログラムコード手段を転送し又は記憶するのに使用され得るし、汎用若しくは専用コンピュータによってアクセスされ得る。（配線接続、ワイヤレス、又は配線接続若しくはワイヤレスの組み合わせのいずれかの）ネットワーク又は別の通信接続上に情報がコンピュータに転送されるか又は提供されるとき、コンピュータは接続をコンピュータ読取可能な媒体であると適切にみなす。したがって、すべてのかかる接続はコンピュータ可読媒体と適切に称されている。上記組み合わせも、コンピュータ可読媒体の範囲内に含まれるべきである。]
[0055] コンピュータ実行可能命令は、汎用コンピュータ、専用コンピュータ、又は専用処理デバイスに特定の機能又は一群の機能を実行せしめる命令及びデータを例えば含む。本発明は、構造の機能及び／又は方法の動作に対して特定の言語によって説明されてきたが、添付した特許請求の範囲において画定された本発明は、上述した特定の特徴又は動作に必ずしも制限されるというわけではないことが理解されるべきであり、むしろ、上述した特定の特徴又は動作は特許請求の範囲を実装する典型的な形態として開示されている。]
[0056] 本発明は、その精神又は本質的な特徴より出発することなく、他の形態により具体化され得る。上述した実施形態は、すべての点において単なる実例として考慮されるべきであり、限定するものではないと考慮すべきである。それゆえに、本発明の範囲は、前述した説明ではなく、添付した特許請求の範囲に示されている。本特許請求の範囲と均等の意味であり且つ本特許請求の範囲の範囲内にあるすべての変更が、特許請求の範囲に含まれるものとする。]

权利要求:

請求項1
異なるデータシェイプ（１３５、１４０、１４５）に基づく異なる型の構造に対応する１つ以上のデータ要素を使用する１つ以上のアプリケーションプログラム（１２０、１２５、１３０）を含むコンピュータ化された環境のオブジェクト指向システム（１００）において、異なる構造型を使用するアプリケーションが相互利用可能となるように共通データ構造（１１０）を使用して、異なる構造型のデータへのアクセスをアプリケーションに自動的に提供する方法であって、１つ以上の異なるアプリケーション（１２５、１３０）によって保持されたデータ（１２７、１３３）に対して、１つ以上のアクセス要求（１８０）をアプリケーション（１２０）から受信する動作（３４０）と前記１つ以上の異なるアプリケーションに対応する１つ以上のプロキシ（１６５、１７０、１７５）を識別する動作（３５０）と、当該識別された１つ以上のプロキシを使用して、当該要求されたデータを共通データ（１１０）構造にマップする動作（３６０）と、当該マップされたデータ構造（１９５）を前記要求するアプリケーションに提供する動作（３７０）とを含み、前記要求されたデータは１つ以上の異なる型の構造に対応し、前記識別された１つ以上のプロキシは、当該要求されたデータ（１２７、１３３）を前記共通データ構造（１１０）にマップするマップされたデータ構造（１９５）を作成することを特徴とする方法。
請求項2
前記識別されたプロキシのうちの少なくとも１つが、１つ以上の異なるアプリケーションプログラムのうちの１つによって提供されることを特徴とする請求項１に記載の方法。
請求項3
前記識別されたプロキシのうちの少なくとも１つが、前記システム（１００）によって１つ以上の異なるアプリケーションプログラムのうちの１つに提供されたデフォルトであることを特徴とする請求項１に記載の方法。
請求項4
前記共通データ構造（１１０）における複数の構造型のうちの１つを前記要求されたデータに割り当てる動作をさらに含む請求項１に記載の方法。
請求項5
前記１つ以上の異なるアプリケーション（１２５、１３０）の各々において前記要求されたデータに対して、１つ以上のデータシェイプ（１３５、１４０、１４５）を識別する動作をさらに含む請求項４に記載の方法。
請求項6
前記共通データ構造（１１０）は、オペレーションに対する構造型、シーケンスに対する構造型、レコードに対する構造型、及び認識不可能なデータシェイプを有するデータに対する構造型を含むことを特徴とする請求項４に記載の方法。
請求項7
前記要求されたデータをマップする前記動作は、前記１つ以上のデータシェイプ（１３５、１４０、１４５）の１つが、値を返す引数又は関数に対応することを判断する動作と、前記１つのデータシェイプ（１３５）に対応する要求されたデータをオペレーションの構造型に割り当てる動作とをさらに含むことを特徴とする請求項６に記載の方法。
請求項8
前記要求されたデータをマップする前記動作は、前記要求されたデータのうちの少なくともいくつかは未定義のデータシェイプに対応することを判断する動作と、前記少なくともいくつかのデータを未定義のデータシェイプに対する構造型に割り当てる動作をさらに含むことを特徴とする請求項６に記載の方法。
請求項9
前記要求されたデータをマップする前記動作が、前記１つ以上のデータシェイプ（１３５、１４０、１４５）のうちの１つが値の集合に対応すると判断する動作をさらに含むことを特徴とする請求項６に記載の方法。
請求項10
前記値の集合が識別可能なラベルを有しないことを判断する動作と、前記データの集合をシーケンスの構造型に割り当てる動作とをさらに含む請求項９に記載の方法。
請求項11
前記値の集合は１つ以上の識別可能なラベルを有することを判断する動作と、前記データの集合をレコードの構造型に割り当てる動作と、をさらに含む請求項９に記載の方法。
請求項12
１つ以上の要求を受信して、前記要求されたデータのうちの少なくともいくつかに対して１つ以上のオペレーションを実行する動作と、前記マップされたデータ構造（１９５）を介して前記１つ以上のオペレーションを処理する動作と、をさらに含む請求項１に記載の方法。
請求項13
オブジェクト指向システム（１００）及びインスツールされた１つ以上のアプリケーションプログラム（１２０、１２５、１３０）を含むコンピュータ化された環境で、異なる型の構造を有する１つ以上のデータ要素を実装するアプリケーションプログラム（１２０）において、共通データ構造（１１０）を介して１つ以上の異なる型の構造に対応するデータにアクセスする方法であって、１つ以上の異なる型の構造に対応するデータ（１２７、１３３）に対して、１つ以上のアクセス要求を送信する動作（３００）と、前記要求されたデータと共通データ構造（１１０）の１つ以上の構造型との間のマッピング情報（２１０、２２０、２３０）を含む１つ以上のマップされたデータ構造（１９５）を受信する動作（３１０）と、当該１つ以上のマップされたデータ構造（１９５）に対する１つ以上の動作（２００）を要求する（３２０）動作と、前記１つ以上の要求された動作が前記１つ以上の異なる型の構造に対応する前記要求されたデータ（１２７、１３３）に対して完了したという１つ以上の確認を受信（３３０）する動作を含み、前記要求された１つ以上の動作は、前記１つ以上の異なる型の構造の前記データ（１２７、１３３）に変換されることを特徴とする方法。
請求項14
前記１つ以上のマップされたデータ構造（１９５）は前記要求されたデータ（１２７、１３３）のうちの少なくともいくつかは１つ以上の値の集合を含むことを示し、前記集合はレコードの構造型に割り当てられることを特徴とする請求項１３に記載の方法。
請求項15
１つ以上のオペレーションを要求する前記動作（３２０）は、前記１つ以上の値のうちの１つに対応するレコードの変化を要求する動作をさらに含み、前記１つ以上の確認は、前記変更が前記レコードにおいて完了されたことを識別することを特徴とする請求項１６に記載の方法。
請求項16
前記１つ以上のマップされたデータ構造（１９５）は、前記要求されたデータ（１２７、１３３）のうちの少なくともいくつかがオペレーションの構造型に割り当てられる１つ以上の関数を含むことを示す特徴とする請求項１３に記載の方法。
請求項17
１つ以上のオペレーションを要求する前記動作（３２０）は、前記オペレーション構造型に対応する１つ以上の関数が、前記要求されたデータ（１２７、１３３）を保持する異なるアプリケーション（１２５、１３０）によって実行されることを要求する動作をさらに含み、前記１つ以上の確認が前記１つ以上の機能が実行されたことを示すことを特徴とする請求項１６に記載の方法。
請求項18
異なるデータシェイプ（１３５、１４０、１４５）に基づく異なる型の構造に対応する１つ以上のデータ要素を使用する１つ以上のアプリケーションプログラム（１２０、１２５、１３０）を含むコンピュータ化された環境のオブジェクト指向システム（１００）において、記憶されたコンピュータ実行命令を有するコンピュータプログラム記憶プロダクトであって、前記記憶されたコンピュータ実行命令が実行されると、１つ以上の異なるアプリケーション（１２５、１３０）によって保持されたデータ（１２７、１３３）に対して、１つ以上のアクセス要求（１８０）をアプリケーション（１２０）から受信する動作（３４０）と、前記１つ以上の異なるアプリケーションに対応する１つ以上のプロキシ（１６５、１７０、１７５）を識別する動作（３５０）と、当該識別された１つ以上のプロキシを使用して、当該要求されたデータを共通データ（１１０）構造にマップする動作（３６０）と当該マップされたデータ構造（１９５）を前記要求するアプリケーションに提供する動作（３７０）とを含む方法を前記システムの１つ以上のプロセッサに実行せしめ、前記要求されたデータは１つ以上の異なる型の構造に対応し、前記識別された１つ以上のプロキシは、当該要求されたデータ（１２７、１３３）を前記共通データ構造（１１０）にマップするマップされたデータ構造（１９５）を作成することを特徴とするコンピュータプログラム記憶製品。